專業理論：

根本原因－控制平面與數據平面的混淆： 所有注入漏洞的本質，都是因為應用程式將來自數據平面（不受信任的用戶輸入）的數據，錯誤地解析為控制平面（程式碼、指令、查詢）的一部分。

SQL Injection 的攻擊向量分類：

帶內注入 (In-band)： 攻擊結果直接在當前的 HTTP 回應中返回。

基於錯誤 (Error-based)： 透過構造非法的語法，使資料庫返回包含敏感資訊的錯誤訊息。

基於聯合查詢 (Union-based)： 利用 UNION 操作符將惡意查詢的結果拼接到原始查詢的結果中一併返回。

帶外注入 (Out-of-band)： 攻擊結果不直接返回，而是透過其他通道（如 DNS 查詢、HTTP 請求）將數據傳出。

推斷注入 (Inferential / Blind)： 應用程式不返回任何數據細節，只能透過構造條件式查詢，觀察應用的布林反應 (Boolean-based) 或時間延遲 (Time-based) 來推斷資訊。

超越 SQLi： 我必須將「注入」的思維模式應用到所有解析器：

作業系統命令注入 (OS Command Injection)： 當用戶輸入被拼接到 system(), exec() 等函數中。

LDAP 注入： 當用戶輸入被用於構造 LDAP 查詢語句。

NoSQL 注入： 針對 MongoDB 等 NoSQL 資料庫的查詢注入，通常利用 JSON 結構和操作符 ($gt, $ne)。

範本注入 (Template Injection)： 在伺服器端渲染範本時，注入能被範本引擎執行的指令。

在 DVWA 中，我需要從 Low 到 High 安全級別，分析其原始碼，看它是如何透過 mysql_real_escape_string 或預備語句 (Prepared Statements) 來防禦 SQLi 的。Burp Intruder 是我自動化測試盲注的利器，可以透過 grep 回應內容或測量回應時間來判斷條件是否成立。

參數化查詢 (Parameterized Queries) 或預備語句 (Prepared Statements) 為何是防禦 SQL Injection 的根本性解決方案？請從資料庫解析查詢的底層機制來解釋其原理。